Many organizations are embracing the paradigm of Model Based Development in their production processes. “Model Based Development” refers to the practice of specifying, analyzing, and implementing systems using a common “model” consisting of a set of block diagrams and associated objects. System implementation typically consists of automatically generating code for portions of the model, particularly portions corresponding to the system's control algorithm.
Graphical modeling environments are programs that enable a user to construct and analyze a model of a process or system. Examples of graphical modeling tools include time-based block diagrams, such as Simulink from The MathWorks Inc., discrete event diagrams and reactive state machine diagrams, such as those found within Stateflow® also available from The MathWorks, Inc., data-flow diagrams, such as LabVIEW, available from National Instruments Corporation, and software diagrams and other graphical programming environments, such as Unified Modeling Language (UML) diagrams.
Some graphical modeling environments also enable simulation and analysis of models. Simulating a dynamic system in a graphical modeling environment is typically a two-step process. First, a user creates a graphical model, such as a block diagram, of the system to be simulated. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts relationships between the systems inputs, states, parameters and outputs. After creation of the graphical model, the behavior of the dynamic system is simulated using the information entered into the graphical model. In this step, the graphical model is used to compute and trace the temporal evolution of the dynamic systems' outputs (“execute the graphical model”), and automatically produce either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of the model (code generation).
Block diagrams are graphical entities having an “executable meaning” that are created within graphical modeling environments for modeling a dynamic system, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system is represented schematically as a first collection of graphical objects, such as nodes, which are interconnected by another set of graphical objects, generally illustrated as lines, which represent logical connections between the first collection of graphical objects. In most block diagramming paradigms, the nodes are referred to as “blocks” and drawn using some form of geometric object (e.g., circle, rectangle, etc.). The line segments are often referred to as “signals”. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition of the relationship between the signals and the state variables is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a port. The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination node of this signal read from the signal when their system equations are being solved. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
It is worth noting that block diagrams are not exclusively used for representing time-based dynamic systems but also for other models of computation. For example, in Stateflow®, flow charts are block diagrams used to capture behavior of reactive systems and process flow. Data flow blocks are block diagrams that describe a graphical programming paradigm where the availability of data is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks.
The functional attributes for a block may affect the dynamics of the model using this block. These attributes are specified for the block as a whole and the input and output ports of the block. Examples of block attributes include block sample times and restrictive flags. Block sample times specify if the block corresponds to an elemental, continuous, discrete, or hybrid dynamic system. If the block is an elemental discrete-time system, then the attribute specifies the spacing between time instants at which the block response should be traced. A restrictive flag disallows the use of blocks in certain modeling contexts. For example, one may impose the restriction that there may only be one instance of given block in a model. Attributes of block ports specify properties of the data that is either available or produced at that port. Block port attributes include dimensions, datatypes, sample rates, and direct feedthrough. Dimension attributes are individual dimensions of a multi-dimensional matrix that is used as a container for data elements. Datatype attributes are the datatype of each element of data in the data container. A complexity attribute is a flag to specify if each data element is real or complex. A sample rate attribute specifies how when the signal corresponding to an input or output port will be used.
The video data is provided as a sequence of images in time. Each time-sample of the image sequence is a video frame. The information contained in each video frame is defined over a two-dimensional spatial grid, whose elements are known as the picture elements or pixels. If the image is gray scale, a single scalar value is assigned to each pixel representing the brightness (intensity of the light) in that element. If the image is in color, a vector is assigned to each pixel containing information regarding brightness (luminance) or the color content (chrominance) or both in that element. A multidimensional array or multiple two-dimensional matrices may also be used to represent color images.
Color video data is often provided in a tri-stimulus model format. Examples of suitable tri-stimulus model formats include, but are not limited to, RGB, YUV, LAB, YIQ, and HSV. In a tri-stimulus format, three signals are provided, each representing a component of the tri-stimulus format. For example, in the RGB color coordinate system an ordered triplet is used to represent the intensity of the red, green and blue light in each pixel. Thus, a first signal provides the red intensity data, a second signal provides green intensity data, and a third signal provides blue intensity data. Other examples will be apparent to one skilled in the art given the benefit of this disclosure.
In some instances, particularly in embedded systems, a user may wish to insert or overlay graphics on image data being handled by a system. For example, in a digital camera, it is useful to insert or overlay static or dynamic graphic elements indicating the status of the camera on the image being viewed, such as cross-hairs, power indicator, light level indicator, or bounding box indicating area of interest. Currently there is no simple way of providing such capabilities when creating a system in a graphical modeling environment.
As used herein, the term image data refers to data handled by a system that represents visual images. Video data is a type of image data that represents video images, such as those provided by a video camera. The terms graphics or graphic elements are used herein in reference to image data that is generated or synthesized locally in the modeled system for addition to provided image data such as video data.